home *** CD-ROM | disk | FTP | other *** search
- Path: engnews1.Eng.Sun.COM!taumet!clamage
- From: thp@cs.ucr.edu (Tom Payne)
- Newsgroups: comp.std.c++
- Subject: Re: Referencing pointers after delete
- Date: 22 Mar 1996 22:20:52 GMT
- Organization: University of California, Riverside
- Approved: clamage@eng.sun.com (comp.std.c++)
- Message-ID: <4iv8bd$5vh@galaxy.ucr.edu>
- References: <4is05t$ceo@engnews1.Eng.Sun.COM> <4is1a5$cag@engnews1.Eng.Sun.COM>
- NNTP-Posting-Host: taumet.eng.sun.com
- X-Nntp-Posting-Host: corvette.ucr.edu
- X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
- Content-Length: 1212
- X-Lines: 26
- Originator: clamage@taumet
-
- Steve Clamage (clamage@Eng.Sun.COM) wrote:
- : In article ceo@engnews1.Eng.Sun.COM, "joe (j.) halpin" <jhalpin@bnr.ca>
- : writes:
- : >
- : >In 3.7.3.2.4 the January working paper says:
- : >
- : >4 A deallocation function can free the storage referenced by the pointer
- : > given as its argument and renders the pointer invalid. The storage
- : > can be made available for further allocation. An invalid pointer con-
- : > tains an unusable value: it cannot even be used in an expression.
- [...]
- : The reason for the odd-looking condition (which follows the C
- : standard) is to allow architectures which validate pointers in
- : hardware to be standard-conforming. Example:
- [...]
- : You can't do anything useful in portable code with uninitialized pointers,
- : or pointers which point to objects which are no longer available. The
- : standard allows the implementation a great deal of leeway in trying to
- : help by identifying such invalid uses.
-
- ... just as for arithmetic exceptions, which also engender "undefined
- behavior." But why the leeway to, say, reformat the disk, rather
- than specifying the normal practice, which is to invoke a signal
- handler, thereby, keeping the behavior defined?
-
- Tom Payne (thp@cs.ucr.edu)
-
-
- [ comp.std.c++ is moderated. To submit articles: try just posting with ]
- [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
- [ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
- [ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
- [ Comments? mailto:std-c++-request@ncar.ucar.edu ]
-